1. Field of the Invention
The present invention is situated in the field of design of systems. More specifically, the present invention is related to a design apparatus for digital systems, generating implementable descriptions of said systems.
The present invention is also related to a method for generating implementable descriptions of said systems.
2. Description of the Related Technology
The current need for digital systems forces contemporary system designers with ever increasing design complexities in most applications where dedicated processors and other digital hardware are used, demand for new systems is rising and development time is shortening. As an example, currently there is a high interest in digital communication equipment for public access networks. Examples are modems for Asymmetric Digital Subscriber Loop (ADSL) applications, and up- and downstream Hybrid Fiber-Coax (HFC) communication. These modems are preferably implemented in all-digital hardware using digital signal processing (DSP) techniques. This is because of the complexity of the data processing that they require. Besides this, these systems also need short development cycles. This calls for a design methodology that starts at high level and that provides for design automation as much as possible.
One frequently used modeling description language is VHDL (VHSIC Hardware Description Language), which has been accepted as an IEEE(copyright) standard since 1987. VHDL is a programming environment that produces a description of a piece of hardware. Additions to standard VHDL can be to implement features of Object Oriented Programming Languages into VHDL. This was described in the paper OO-VHDL (Computer, October 1995, pages 18-26). Another frequently used modeling description language is VERILOG(copyright).
A number of commercially available system environments support the design of complex DSP systems.
MATLAB(copyright) of Mathworks Inc offers the possibility of exploration at the algorithmic level. It uses the data-vector as the basic semantical feature. However, the developed MATLAB(copyright) description has no relationship to a digital hardware implementation, nor does MATLAB(copyright) support the synthesis of digital circuits.
SPW of Alta Group offers a toolkit for the simulation of these kinds of systems. SPW is typically used to simulate data-flow semantics. Data-flow semantics define explicit algorithmic iteration, whereas data-vector semantics do not. SPW relies on an extensive library and toolkit to develop systems. Unlike MATLAB(copyright), the initial description is a block-based description. Each block used in the systems appears in two different formats, (a simulatable and a synthesizable version) which results in possible inconsistency.
COSSAR(copyright) of Synopsys performs the same kind of system exploration as SPW.
DC and BC are products of Synopsys that support system synthesis. These products do not provide sufficient algorithm exploration functions.
Because all of these tools support only part of the desired functionality, contemporary digital systems are designed typically with a mix of these environments. For example, a designer might do algorithmic exploration in MATLAB, then do architecture definition with SPW, and finally map the architecture definition to an implementation in DC.
It is an aim of the present invention to disclose a design apparatus that allows to generate from a behavioral description of a digital system, an implementable description for said system.
It is another aim of the present invention to disclose a design apparatus that allows for designing digital systems, starting from a data vector or data flow description, and generating an implementable level such as VHDL. A further aim is to perform such design tasks within one object oriented environment.
Another aim is to provide a means comprised in said design apparatus for simulating the behavior of the system at any level of the design stage or trajectory.
A first aspect of the present invention concerns a design apparatus compiled on a computer environment for generating from a behavioral description of a system comprising at least one digital system part, an implementable description for said system, said behavioral description being represented on said computer environment as a first set of objects with a first set of relations therebetween, said implementable description being represented on said computer environment as a second set of objects with a second set of relations therebetween, said first and second set of objects being part of a design environment.
A behavioral description is a description which substantiates the desired behavior of a system in a formal way. In general, a behavioral description is not readily implementable since it is a high-level description, and it only describes an abstract version of the system that can be simulated. An implementable description is a more concrete description that is, in contrast to a behavioral description, detailed enough to be implemented in software to provide an approximative simulation of real-life behavior or in hardware to provide a working semiconductor circuit.
With design environment is meant an environment in which algorithms can be produced and run by interpretion or compilation.
With objects is meant a data structure which shows all the characteristics of an object from an object oriented programming language, such as described in xe2x80x9cObject Oriented Designxe2x80x9d (G. Booch, Benjamin/cummings Publishing, Redwood City, Calif., 1991).
Said first and second set of objects are preferably part of a single design environment.
Said design environment comprises preferably an Object Oriented Programming Language (OOPL). Said OOPL can be C++.
Said design environment is preferably an open environment wherein new objects can be created. A closed environment will not provide the flexibility that can be obtained with an open environment and will limit the possibilities of the user.
Preferably, at least part of the input signals and output signals of said first set of objects are at least part of the input signals and output signals of said second set of objects. Essentially all of the input signals and output signals of said first set of objects can be essentially all of the input signals and output signals of said second set of objects.
At least part of the input signals and output signals of said behavioral description are preferably at least part of the input signals and output signals of said implementable description. Essentially all of the input signals and output signals of said behavioral description can be essentially all of the input signals and output signals of said implementable description.
Said first set of objects has preferably first semantics and said second set of objects has preferably second semantics. With semantics is meant the model of computation. Said first semantics is preferably a data-vector model and/or a data-flow model. Said second semantics is preferably a Finite State Machine Data Path (FSMD) data structure, comprising a control part and a data processing part, the data processing part being modeled by a signal flow graph (SFG) data structure and the control part being modeled by a FSM data structure. The terms FSMD and SF are used interchangeably throughout the text.
Preferably, the impact in said implementable description of at least a part of the objects of said second set of objects is essentially the same as the impact in said behavioral description of at least a part of the objects of said first set of objects.
Preferably, the impact in said implementable description of essentially all of the objects of said second set of objects is essentially the same as the impact in said behavioral description of essentially all of the objects of said first set of objects.
With impact is meant not only the function, but also the way the object interacts with its environment from an external point of view. A way of rephrasing this is that the same interface for providing input and collecting output is present. This does not mean that the actual implementation of the data-processing between input and output is the same. The implementation is embodied by objects, which can be completely different but perform a same function. In an OOPL, the use of methods of an object without knowing its actual implementation is referred to as information hiding.
The design apparatus preferably further comprises means for simulating the behavior of said system said means simulating the behavior of said behavioral description, said implementable description or any intermediate description therebetween. Said intermediate description can be obtained after one or several refining steps from said behavioral description.
Preferably, at least part of said second set of objects is derived from objects belonging to said first set of objects. This can be done by using the inheritance functionalities provided in an OOPL. Essentially all of said second set of objects can be derived from objects belonging to said first set of objects.
Said implementable description can be essentially obtained by refining said behavioral description. Preferably, said refining comprises the refining of objects. The design apparatus can further comprise means to derive said first set of objects from a vector description, preferably a MATLAB(copyright) description, describing said system as a set of operations on data vectors, means for simulating static or demand-driven scheduled dataflow on said dataflow description and/or means for clock-cycle true simulating said digital system using said dataflow description and/or one or more of said SFG data structures.
The design apparatus can further comprise means to derive said first set of objects from a vector description, preferably a MATLAB description, describing said system as a set of operations on data vectors, means for simulating statically or demand-driven scheduled dataflow on said dataflow description and/or means for clock-cycle true simulating said digital system using said dataflow description and/or one or more of said SFG data structures.
In a preferred embodiment, said implementable description is an architecture description of said system, said system advantageously further comprising means for translating said architecture description into a synthesizable description of said system, said synthesizable description being directly implementable in hardware. Said synthesizable description is preferably a netlist of hardware building blocks. Said hardware is preferably a semiconductor chip or a electronic circuit comprising semiconductor chips.
A synthesizable description is a description of the architecture of a semiconductor that can be synthesized without further processing of the description. An example is a VHDL description.
Said means for translating said architecture description into a synthesizable description can be Cathedral-3 or Synopsys DC.
A second aspect of the present invention is a method for designing a system comprising at least one digital part, comprising a refining step wherein a behavioral description of said system is transformed into an implementable description of said system, said behavioral description being represented as a first set of objects with a first set of relations therebetween and said implementable description being represented as a second set of objects with a second set of relations therebetween.
Said refining step preferably comprises translating behavioral characteristics at least partly into structural characteristics. Said refining step can comprise translating behavioral characteristics completely into structural characteristics.
Said method can further comprise a simulation step in which the behavior of said behavioral description, said implementable description and/or any intermediate description therebetween is simulated.
Said refining step can comprises the addition of new objects, permitting interaction with existing objects, and adjustments to said existing objects allowing said interaction.
Preferably, said refining step is performed in an open environment and comprises expansion of existing objects. Expansion of existing objects can include the addition to an object of methods that create new objects. Said object is said to be expanded with the new objects. The use of expandable objects allows to use meta-code generation: creating expandable objects implies an indirect creation of the new objects.
Said behavioral description and said implementable description are preferably represented in a single design environment, said single design environment advantageously being an Object Oriented Programming Language, preferably C++.
Preferably, said first set of objects has first semantics and said second set of objects has second semantics. Said first semantics is preferably a data-vector model and/or a data-flow model. Said second semantics is preferably an SFG data structure.
The refining step comprises preferably a first refining step wherein said behavioral description being a data-vector model is at least partly transformed into a data-flow model. Advantageously, said data-flow model is an untimed floating point data-flow model.
Said refining step preferably further comprises a second refining step wherein said data-flow model is at least partly transformed into an SFG model. Said data-flow model can be completely transformed into an SFG model.
In a preferred embodiment, said first refining step comprises the steps of determining the input vector lengths of input, output and intermediate signals, determining the amount of parallelism of operations that process input signals under the form of a vector to output signals, determination of objects, connections between objects and signals between objects of said data-flow model, and determining the wordlength of said signals between objects. In the sequel of this application, the term xe2x80x9cactorsxe2x80x9d is also used to denote objects. Connections between objects are denoted as xe2x80x9cedgesxe2x80x9d and signals between objects are denoted as xe2x80x9ctokensxe2x80x9d. Said step of determining the amount of parallelism can preferably comprise determining the amount of parallelism for every data vector and reducing the unspecified communication bandwidth of said data-vector model to a fixed number of communication buses in said data-flow model. Said step of determination of actors, edges and tokens of said data-flow model preferably comprises defining one or a group of data vectors in said first data-vector model as actors; defining data precedences crossing actor bounds, as edges, said edges behaving like queues and transporting tokens between actors; construct a system schedule and run a simulation on a computer environment. Said second refining step comprises preferably transforming said tokens from floating point to fixed point. Preferably, said SFG model is a timed fixed point SFG model.
Said second set of objects with said second set of relations therebetween are preferably at least partly derived from said first set of objects with said first set of relations therebetween. Objects belonging to said second set of objects are preferably new objects, identical with and/or derived by inheritance from objects from said first set of objects, or a combination thereof.
Several of said SFG models can be combined with a finite state machine description resulting in an implementable description. Said implementable description can be transformed to synthesizable code, said synthesizable code preferably being VHDL code.
Another aspect of the present invention is a method for simulating a system, wherein a description of a system is transformed into compilable C++ code.
Preferably, said description is an SFG data structure and said compilable C++ code is used to perform clock cycle true simulations.
Several SFG data structures can be combined with a finite state machine description resulting in an implementable description, said implementable description being said compilable C++ code suitable for simulating said system as software.
A clock-cycle true simulation of a system uses one or more SFG data structures.
Said clock-cycle true simulation can be an expectation-based simulation, said expectation-based simulation comprising the steps of: annotating a token age to every token; annotating a queue age to every queue; increasing token age according to the token aging rules and with the travel delay for every queue that has transported the token; increasing queue age with the iteration time of the actor steering the queue, and; checking whether token age is never smaller than queue age throughout the simulation.
Another aspect of the present invention is a hardware circuit or a software simulation of a hardware circuit designed with the design apparatus as recited higher.
Another aspect of the present invention is a hardware circuit or a software simulation of a hardware circuit designed with the method as recited above.
The present invention will be further explained by means of examples, which does not limit the scope of the invention as claimed.